再來要介紹另一個與Agile很相像的，Lean 精實開發，也是藉由此次鐵人賽探討DevOps我才第一次看到這個名詞，為什麼要介紹他呢？除了是因為跟敏捷很相像，也是因為後面在說DevOps的時候會有關，因此先利用此篇來探討一下

上網多搜尋幾篇文章介紹，大家都會提到Lean Software Development的源起來自於「Toyota 的TPS生產系統」，重點核心為Just-In-Time流程，強調隨時檢討，將各成本降到最低避免浪費

有七個原則呼應Just-In-Time的觀念：

• 消除浪費（Eliminate waste）
• 增強學習（Amplify learning）
• 延遲決策（Decide as late as possible）
• 加速發布（Deliver as fast as possible）
• 尊重授權（Empower the team）
• 嵌入完整性（Build integrity in）
• 全局思考（Optimize the whole）

消除浪費（Eliminate waste）

任何東西只要對客戶來說沒有附加價值的都屬於浪費，研究指出軟體開發常見的八種浪費：

1. Partially done work：預先完成成品，但不能確定日後是否真有其功能需求或過時
2. Extra Processes：過多的流程，例如不必要的紙本簽核
3. Extra features：開發過多/額外的功能
4. Task switching：一個人同時需要執行多個工作
5. Waiting：等待確認、等待簽核、等待文件....
6. Motion： 當遇到問題的時候是否有去處理協調
7. Defects：沒有及時發現問題
8. Management activities：過多不必要的管理

為了要盡量減少浪費，首先要先能夠理解、識別什麼樣的項目是屬於浪費，例如某個項目是可以被跳過或者移除也能夠達到最終目標的，那就是一種浪費；開發過程中不被使用到的功能、程式碼，也是一種浪費.....

增強學習（Amplify learning）

軟體技術不斷地推成出新，開發流程也是一直因應著時間趨勢改變，不管是個人亦或是團隊，都需要不斷的精進才能跟上時代的腳步，可以說這是一條需要不斷學習的路。

• 使用短週期來檢視與反饋，能夠快速調整先前的不足，加速學習的能力
• 避免累積問題或技術債，程式寫好就是立即測試，且適量進行重構與整合測試
• 與其寫一大堆的文件，不如寫好程式和做出測試來驗證一下想法對不對
• 頻繁與客戶溝通，確認需求，釐清目標與未來方向
• 客戶可提供回饋供開發團隊調整，開發團隊亦可藉由與客戶溝通更深入了解domain know-how

延遲決策（Decide as late as possible）

專案往往不確定性很多，包含需求不明確，甚至有時候客戶自己也不知道自己要什麼，因此盡量的延遲決策的時間點，保留多方案的彈性是很重要的，因應隨時會調整的變化。我個人的想法是，因為需求會與時俱進，要完全凍結固定需求是有難度的，因此在設計與開發時都要保有彈性空間，好去應變各式各樣的調整，至於怎麼才叫做有彈性，這就要看經驗和運氣（真的還是有遇過上線前一個禮拜，整個UI翻掉的要求，這種不管多大的彈性還是有必然的成本耗損）

加速發布（Deliver as fast as possible）

這是敏捷中很精華的重點，加速發布有助於更快地獲得客戶反饋，來調整產品的品質與內容，透過小批量的調整，快速迭代更新

尊重授權（Empower the team）

讓團隊中的每個成員都有權利提出想法，有別於過去只是將人當作資源看待，讓團隊的人員都有參與在其中，才能更加加深每個人的融入狀況與提升士氣，同時培養人才

嵌入完整性（Build integrity in）

導入自動化測試，輔助每次異動的測試流程，同時在設計與測試時，每個環境都應該考慮整體系統的完整度，不只是內部的，還有包含外部的，甚至系統流程外的商業流程，有更完整的環節，能有更好的品質

全局思考（Optimize the whole）

一個系統開發完成不會只有一個團隊，一定有多個團隊需要合作，要將思考格局放大，將所有相關的夥伴納入，並密切溝通、資訊透明化，得以降低成本消除隔閡

此為精實軟體開法的七大主軸，說來容易，但其實裡面還有很多的細節需要注意，待我們去實作並瞭解

參考資料、延伸閱讀：

• Lean Software Development的七個原則與管理觀念
• 從精實軟體開發到精實創業
• 8件事，精實開發非用看板方法不可
• Lean Software Development: An Agile Toolkit

下集預告：What is DevOps？